Insurance policies are known in the art and comprise complex legal agreements that specify items to be afforded coverage with respect to particular perils. Numerous conditions typically apply including applicable deductibles, coverage limits, and so forth. Modern insurance policies also often include expense/billing information that breaks down the total cost of the agreement into elements by covered item and peril.
Insurance carriers often view such policies as being derived from and related to a “policy product”. A policy product defines the attributes and shared data for its derived policies. The process of writing a specific policy involves referring to the available attributes of the policy as defined by the policy product and the corresponding selection of appropriate values for a given customer. For example, when writing a commercial package policy, the insurer will typically refer to a commercial package policy product to ascertain that such a policy contains coverage with respect to general liability, commercial property, and other more specialized kinds of coverage. The insurer then uses this information to facilitate capture of additional information to fully define the policy and price it.
Insurance policies are typically defined at various levels of granularity with a collection of coverages typically comprising a most basic level of resolution. A coverage comprises an obligation to pay for damages that are caused by a particular peril (or collection of perils). The obligation typically has corresponding financial limits and deductibles that circumscribe the insurer's responsibility for losses against that coverage. A policy's total cost is usually determined as a function of the aggregate cost of the policy's constituent coverages.
Coverages typically apply to risk units (that is, a thing or circumstance that may be exposed to loss). For example, risk units can comprise buildings, vehicles, personal property, on-going business, or the like. At a higher level, coverages and associated risk units are grouped together to form a “policy line,” which describes a set of coverages that apply to a particular business operation. In the insurance industry, policy line is often used interchangeably with “line of business,” however, the term “policy line” will be used herein for consistency. A policy product comprises one or more policy lines. Typical policy lines include, but are not limited to, personal auto, general liability, commercial property, inland marine, and so forth.
Insurance policies are drafted in relatively high volumes. At the same time there can be considerable diversity with respect to the particulars of such policies. Word processing and other software-based applications have been helpful to facilitate the provisioning of insurance policies but have not fully addressed the needs of the industry. Policy product definitions are typically used to facilitate the drafting of a new policy, by providing a reference for the attributes of a policy. If the policy product is represented in a computer software application at all, it is usually hardcoded into a corresponding policy administration application. That is, such a system will typically directly encode the coverages, risk units, and policy lines into program code. In a typical implementation each kind of risk unit, coverage, and policy line has its own separate database tables, screens, and processing logic.
Such an approach presents several drawbacks. This approach does not support managing new policy lines, coverage types, or risk units that are not already hardcoded into the system. Instead, such new information must itself be specifically encoded into each and every instance where applicability is sought. As a result, even relatively small changes can require extensive software changes. This can be time consuming and expensive. This approach also carries considerable risk as the very act of making such coding changes presents a risk to the existing product definition as it is currently programmed.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.